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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by the Joint Technical Committee (JTC) Broadcast of the 
European Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the 
European Telecommunications Standards Institute (ETSI). 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 60 
countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 

Founded in September 1993, the DVB Project is a market-led consortium of public and private sector organizations in 
the television industry. Its aim is to establish the framework for the introduction of MPEG-2 based digital television 
services. Now comprising over 200 organizations from more than 25 countries around the world, DVB fosters 
market-led systems, which meet the real needs, and economic circumstances, of the consumer electronics and the 
broadcast industry. 

The present document is part 1 of a multi-part deliverable covering DVB System Software Update Specification, as 
identified below: 

Part 1: "Simple Profile"; 

Part 2: "Extended Profile". 



Introduction 

The present document defines agreements on which to base interoperability for system software update services and 
receivers. These have been selected to minimize interdependencies between the parties involved. In particular: 

It defines the signalling information that can be used to locate the transport stream containing the system 
software update service in a network via the NIT or BAT as appropriate. 

It defines the signalling information used to locate the system software update service in a transport stream (via 
the PMT). 

It defines the options for transmitting the actual system software update service in either a proprietary data 
transfer format, or a standardized 2-layer DVB data carousel (called standard update carousel from here on). 
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It defines an Update Notification Table (UNT) that can be used to enhance the system software update 
functionality in an upward compatible way. The table provides a standard mechanism for carrying additional 
information, e.g. update scheduling information, extensive selection and targeting information, action 
notification, filtering descriptors. 

It defines a recommended format for exchanging the system software update data from receiver manufacturer to 
the network (or multiplex) operator for subsequent transmission. In case multiple receiver manufacturers share 
the same standard update carousel this format allows such a multi-vendor carousel to be composed from 
individual manufacturers contributions in a simple way. 

The present document has to be seen in context with ETR 162 [3] and EN 300 468 [4] because it describes additional 
descriptors used for system software update. 
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Scope 



The present document specifies a standard mechanism for signalHng a software update service and the means to carry 
the data for such a software update service. Since receiver software is increasingly complex, such a software update 
service is required to guarantee the functionality of a receiver as well as to increase its functionality once deployed in 
the field. 

The present document builds on [1], [3] and [4] for signalling and on [2] for data carriage. 

The present document does not define the mandatory character of this protocol in a specific context, and it does not 
exclude the use of proprietary mechanisms for doing a software update. This allows a network to support horizontal 
market model receivers (e.g. MHP receivers). Equally it allows receivers requiring a software update service to be 
deployed in a network independent way. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

[1] ISO/IEC 13818-6 (1998): "Information technology - Generic coding of moving pictures and 

associated audio information - Part 6: Extensions for DSM-CC". 

[2] ETSI EN 301 192 (Vl.2.1): "Digital Video Broadcasting (DVB); DVB specification for data 

broadcasting". 

[3] ETSI ETR 162: "Digital Video Broadcasting (DVB); Allocation of Service Information (SI) codes 

for DVB systems". 

[4] ETSI EN 300 468: "Digital Video Broadcasting (DVB); Specification for Service Information (SI) 

in DVB systems". 

[5] IEEE 802-1990: "IEEE Standard for Local and Metropolitan Area Networks: Overview and 

Architecture". 



3 Definitions and Abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

(receiver) manufacturer: organization which assumes prime responsibility for updating this software of a receiver 
once deployed in the field 

NOTE: Depending on legal arrangements this can also apply to service providers and other entities. 

system software update: update of receiver software transmitted over the DVB systems 
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3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

BAT Bouquet Association Table 

bslbf bit string, left bit first 

DDB Download Data Block 

DII Download Info Indication 

DSI Download Server Initiate 

DSM-CC Digital Storage Media - Command and Control 

DVB Digital Video Broadcasting 

EBU European Broadcasting Union 

ISO International Organization for Standardization 

LSB Least Significant Bit 

MHP Multimedia Home Platform 

MPEG Moving Pictures Expert Group 

MSB Most Significant Bit 

NIT Network Information Table 

OUI Organization Unique Identifier 

PMT Program Map Table 

PSI Program Specific Information 

SI Service Information 

TS Transport Stream 

uimsbf unsigned integer most significant bit first 

UNT Update Notification Table 



4 Types of system software update services 

The present document allows three different formats of system software update services: 

1) Proprietary format streams. 

2) Standard update carousel (potentially shared between manufacturers). 

3) Update Notification Table based system software update services. 

The data_broadcast_id_descriptor identifies the system software update stream. System software update services can 
contain data of one or multiple receiver manufacturers. 

In case of (1) it is the responsibility of the receiver manufacturers potentially sharing the update service to identify their 
organization's stream, or the stream can be uniquely identified as being specific to a receiver manufacturer through the 
data_broadcast_id_descriptor. 

In case of (2) the standard carousel contains the identification of the receiver manufacturer. 

In case of (3) selection information is passed in one or more specific UNTs optionally carrying multiple selection and 
targeting descriptors. This or these tables are referenced in the PMT. 



Network (SI) Signalling 



The linkage descriptor with the linkage type of 0x09 {system software update service) conveys the location of the 
transport stream carrying a system software update service within a network or bouquet respectively. This descriptor 
shall be carried in the first loop of the NIT or in the first loop of a specifically identified BAT (called system software 
update BAT from here on). 

The system software update BAT is identified by the system software update bouquet_id OxFFOO, and if the 
country_availability_descriptor is used, the country code applicable should be 902 (all countries). This allows a receiver 
to quickly identify it. If the system software update BAT is carried in the transport stream of a network it shall be the 
same as in any other transport stream of that network carrying the system software update BAT. 
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NOTE: The preferred positioning of this descriptor is in the NIT. On large networks which operate in a 

partitioned way (typical for satellite) it may be prohibitive to carry this descriptor in the NIT (e.g. due to 
size constraints of the NIT), in which case carriage in the system software update BAT is appropriate. 

If OUIs (plus additional selector bytes) are listed in the linkage_descriptor the list of OUIs shall be complete in that it 
shall convey information about all software upgrades conveyed on the respective service. This allows a receiver to 
conclusively detect that it may not have to further explore a service. A specific OUI with value 0x00015 A has been 
reserved by DVB. This OUI might be used for other purposes despite the System Software Update described in the 
present document. Within the scope of the present document it is used to signal that the data_broadcast_id_descriptor 
does not signal any specific OUI. In that case further selection information shall be carried either in the standard data 
carousel or the Update Notification Table as referenced in the descriptor. If the DVB OUI is used only this single OUI 
shall be contained in the loop of the data_broadcast_id descriptor. There can be multiple descriptors in the NIT or 
system software update BAT to allow multiple system software update services to be identified. It is specifically not the 
intention to remove this descriptor from the NIT or BAT in case of temporary absence of the service. For this purpose 
specific organization identification (OUI) shall not be removed from this descriptor in case of temporary absence of a 
system software update service for receivers of identified organization. 

5.1 Linkage descriptor for systems software update 

Table 1 : Syntax for the private data bytes for linkage type 0x09 





Syntax 


No. of 
bits 


Identifier 


System software update link structure(){ 






OUI_data_length 




8 


uimsbf 


for (i=0; i<N; i++){ 








OUI 




24 


bslbf 


selectorjength 




8 


uimsbf 


for (j=0;j<N;j++){ 








selector byte 
} 




8 


uimsbf 


} 

for (1=0; i<N; i++){ 








private data byte 

} 
} 




8 


uimsbf 



Semantics of the private data bytes for linkage type 0x09: 

OUI_data_length: This field specifies the total length in bytes of the following OUI-loop. 

OUI: This is a 24-bit field containing an IEEE OUI (as described in IEEE 802-1990 [5]) of the organization providing a 
system software update service on the transport-stream/service. DVB has defined OUI OxOOOlSA to signal that the 
stream is from any OUI. 

selectorjength: This 8-bit field specifies the total length in bytes of the following selector field. 

selector_byte: This field provides information additional to the OUI that can be used by a receiver to locate and 
identify the system software update service, e.g. model type or ranges. The syntax and semantics of the selector field are 
defined by the organization owning the OUI. 

private_data_byte: This is an 8-bit field, the value of which is privately defined. 
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PSI signalling 



The PMT of the transport stream carrying system software update data shall contain the data_broadcast_id descriptor 
with the data broadcast id of OxOOOA to indicate the elementary stream used for the system software update service. 

The descriptor is considered essential for the location of a system software update service in all of the following cases: 

• The descriptor provides an entry point to a proprietary stream. 

• The descriptor provides the entry point to a standard two-layer data carousel without further reference from a 
table. 

• The descriptor provides the reference to an Update Notification Table. 

In these cases this descriptor shall be present on a "semi-static" basis: i.e. the identification of the system software 
update service operator shall not be removed from the PMT if there is presently no system software update service, but 
it is expected that there will be in the near future. 

The descriptor may contain specific OUIs (plus selector bytes), in which case the list of OUIs (plus selector bytes) shall 
be complete. 

A specific OUT with value 0x00015 A has been reserved by DVB. This OUI might be used for other purposes despite 
the System Software Update described in the present document. Within the scope of the present document it is used to 
signal that the data_broadcast_id_descriptor does not signal any specific OUI. In that case further selection information 
shall be carried either in the standard data carousel or the Update Notification Table as referenced in the descriptor. If 
the DVB OUI is used only this single OUI shall be contained in the loop of the data_broadcast_id descriptor. There can 
be multiple descriptors in the NIT or system software update BAT to allow multiple system software update services to 
be identified. So it is specifically not the intention to remove this descriptor from the NIT or BAT in case of temporary 
absence of the service. For the same purpose specific organization identification shall not be removed from this 
descriptor in case of temporary absence of a system software update service for receivers of identified organization. 

Where a separate standard update carousel is used for each OUI (plus applicable selector bytes), the 
data_broadcast_id_descriptor in the PMT shall contain the single OUI (plus selector bytes) for each component. This 
allows vendor unique identification of proprietary format streams and provides for additional convenience for the 
receiver in the process to identify the appropriate elementary stream in case there is only one applicable option. 

It should be noted that the data_broadcast_id_descriptor for a system software update service is defining a single 
elementary stream. A single program can encompass multiple elementary streams and thus multiple system software 
update streams (carousels), each of which shall be described by its own data_broadcast_id_descriptor. A system 
software update stream can also be carried as a component of another service, which may simplify network 
management. 
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6.1 Data broadcast id descriptor selector byte definition for 
system software update 

data_broadcast_id: This field shall be set to OxOOOA to indicate a system software update service (see ETR 162 [3]). 
selector_byte: The selector bytes shall convey the system_software_update_info structure which is defined in table 2. 

Table 2: Syntax for the system_software_update_info structure 





Syntax 


No. of 
bits 


Identifier 


system software update info(){ 








OUI data length 




8 


uimsfb 


for (i=0; i<N; i++){ 








OUI 




24 


bslbf 


reserved 




4 




updatejype 




4 




reserved 




2 




update_versioning_flag 




1 




update_version 




5 




selector length 




8 


uimsbf 


for (j=0;j<N;j++){ 








selector byte 
} 




8 


uimsbf 


} 

for (1=0; i<N; !++){ 








private data byte 
} 
} 




8 


uimsbf 



Semantics of the id_selector bytes for data_broadcast_id OxOOOA: 

OUI_data_length: This field specifies the total length in bytes of the following OUI-loop. 

OUI: This is a 24-bit field containing an IEEE OUI (as described in IEEE 802-1990 [5]) of the organization providing a 
system software update service on the transport-stream/service. DVB has defined OUI OxOOOlSA to signal that the 
stream is from any OUI. 

update_type: This is a two-bit field defining the type of the system software update service as indicated in table 3. 

Table 3: Update-type 



Value 


Description 


0x0 


proprietary update solution 


0x1 


standard update carousel (i.e. without notification table) via 
broadcast 


0x2 


system software update with notification table (UNT) via broadcast 


0x3 


system software update using return channel with UNT 


0x4-0xF 


reserved for future use 



update_versioning_flag: If it is no relevant versioning information is carried in the version field. If it is 1 the version 
field shall reflect changes in the system software update service component. 

update_version: The version shall be incremented on each change of the update. If the update_versioning_flag is set to 
1 and the update_type is 01 (UNT) then the update_version field shall be the same as the version_number in the UNT 
section header. 

selector_length: This 8-bit field specifies the total length in bytes of the following selector field. 

selector_byte: This is an 8-bit field. The sequence of selector_byte fields specifies the selector field. This field provides 
information additional to the OUI that can be used by a receiver to locate and identify the system software update 
service, e.g. model type or ranges. The syntax and semantics of the selector field are defined by the organization 
identified by the OUI. 
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7 Standard data carousel layout for system software 

update services 

7.1 Structure of the standard update carousel 

The proposed protocol is based on the DSM-CC data carousel specification (ISO/IEC 13818-6 [1]) and the specification 
of DVB data carousels (EN 301 192 [2]). 

Multiple system software updates of multiple manufacturers are transmitted as groups in a two-layered Data Carousel. 
The DownloadServerlnitiate message (DSI) is used as the entry point in the carousel and is shared by multiple 
manufactures. One manufacturer can have multiple updates, each update in a separate group. 

It is assumed that all groups and modules can be transmitted on a shared elementary stream. 

The DownloadServerlnitiate message describes the downloads (groups) with the GroupInfoByte (gi) field. The 
GroupInfoByte field consists also of a loop of descriptors that may contain miscellaneous information. The 
compatibilityDescriptor of the DSI message is located in the Grouplnfolndication field and allows the identification of 
the manufacturer (using the IEEE OUI). 

Only the DSI is shared by multiple manufacturers, all data in a group will typically belong to one manufacturer. 

Figure 1 illustrates the proposed protocol. In the figure, manufacturer A has one active update and one non-active 
(i.e. scheduled / announced) update (empty group). 

Manufacturer B has one active update. 
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PMT 



data broadcastJd_desc 

QUIA 



OUIB 



DSI transactionID 



QUIA 



gi 

QUIA 



gi 

OUIB 



Active download 
for Manufacturer A 



DM 


transactionID 
















nni 




nni 





Module 



DDB 
Block 



DDB 



DDB 



Group 



Active download 
for Manufacturer B 



Dll transactionID 



nni mi mi 



ill 



DDB DDB DDB 



DDB 



DDB 



DDB 



Group 
Supergroup 



Figure 1 : Multiple updates in a two-layered Data Carousel all sharing the same elementary stream 

A data_broadcast_id_descriptor in the PMT is used to signal the presence of one or more system software updates, of 
one or more manufacturers. 



7.1.1 



DownloadServerlnitiate message (DSI) 



The DownloadServerlnitiate message (DSI) is used as the entry point in the carousel and can be shared by multiple 
manufactures. One manufacturer can have multiple updates, each update in a separate group. 

It is assumed that all groups and modules can be transmitted on a single elementary stream. 

The DownloadServerlnitiate (DSI) message carries the compatibilityDescriptor in the GroupCompatibility field of the 
Grouplnfolndication structure to allow the identification of the manufacturers group (download) using the IEEE OUI. 
The GroupInfoByte (gi) field of the Grouplnfolndication structure can consist of a loop of descriptors that contain 
miscellaneous information for each group. 

In order to allow for multiple updates to be generated independent from each other and transmitted on the same 
carousel, specific assignment rules for some particular fields are given in annex C. 

transactionid: The two least significant bytes of a DSI's transactionid shall be in the range 0x0000-0x0001. The least 
significant bit of actual transaction ID changes every time there is a change to the underlying carousel structure (i.e. a 
group is added, changed or removed) as specified in [2] . 

The two most significant bytes (bits 31. .16) contain a number which identifies the carousel version and can be used to 
detect version changes. 
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serverld: This field shall be set to 20 bytes with the value of OxFF. 

compatib ility Descriptor (): This structure shall only contain the compatibilityDescriptorLength field of the 
CompatibilityDescriptorO as defined in DSM-CC (see ISO/IEC 13818-6 [1]). It shall be set to the value of 0x0000. 

The privateDataByte fields shall contain the Grouplnfolndication structure as defined below: 

privateDataLength: This field defines the length in bytes of the following Grouplnfolndication structure. 

privateDataByte: These fields shall convey the Grouplnfolndication structure as defined in table 4. 

Table 4: Grouplnfolndication structure 



Syntax 


Num. of 
Bytes 


Remarks 




GrouplnfolndicationO { 








NumberOfGroups 


2 


number of updates (maximum 


150) 


for (i = 0; i < NumberOfGroups; i++) { 








Groupid 


4 






GroupSize 


4 






GroupCompatibility 








GrouplnfoLength 


2 






for (i=0; i<N; i++) { 








GrouplnfoByte 


1 






PrivateDataLength 


2 






for(i=0;i< privateDataLength;l++) { 








PrivateDataByte 
} 

} 
} 


1 


not used 





Tables: CompatibilityDescriptor 



Syntax 


Num. of 
Bytes 


Remarks 


CompatibilityDescriptorO { 






CompatibilityDescriptorLengtfn 


2 




DescriptorCount 


2 




for (i = 0; i < descriptorCount; i++) { 






descriptorlype 


1 




descriptorLength 


1 




specifierlype 


1 


0x01 (IEEE QUI) 


SpecifierData 


3 


IEEE GUI as described in IEEE 802-1990 [5] 


model 


2 


is equal to if the model is transmitted in a 
manufacturer private location 


version 


2 


is equal to if the version is transmitted in a 
manufacturer private location 


subDescriptorCount 


1 




for (j = 0; j < subDescriptorCount; j++) { 






subDescriptorO 
} 
} 
} 




not used 



Table 6: DescriptorType 



DescriptorType 


Description 


0x00 


Pad descriptor 


0x01 


System Hardware descriptor. 


0x02 


System Software descriptor. 


0x03- 0x3 F 


ISO/IEC 13818-6 [1] reserved. 


0x40- OxFF 


Private use. 
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Semantics of the Grouplnfolndication structure: 

numberOf Groups: This is a 16-bit field that indicates the number of groups described in the loop following this field. 

Applying the procedure described in annex C, with the LSB of the counter position of the grouplnfo within the 
grouplnfo loop (the download number) is copied to the MSB of the moduleld, the maximum number of downloads is 
limited to 255, which is more than sufficient for a MPEG-2 transport format. 

groupid: This is a 32-bit field which shall be equal to the transactionld of the Downloadlnfolndication message that 
describes the group. 

Applying the procedure described in annex C, the id part is the same as the counter position of the grouplnfo within the 
grouplnfo loop (the download number). The download number is in the range 1 to NumberOfGroups. The range starts 
at 1 to meet the requirement that at least one bit in the least significant bits 1 to 15 of the Dll transactionld has to be 1. 

groupSize: This is a 32-bit field that shall indicate the cumulative size in bytes of all the modules in the group. 

groupCompatibility: The GroupCompatibility structure is equal to the CompatibilityDescriptor structure of DSM-CC. 
The CompatibilityDescriptor should contain a system hardware descriptor containing the OUl that is equal to the OUI 
present in the system_software_update_info structure of the data_broadcast_id_descriptor in the PMT. If multiple 
updates of the same manufacturer are present, the model and version fields in the system hardware descriptor and the 
system software descriptor can be used by the receiver to select the correct stream. Only descriptors of descriptorType 
System Hardware descriptor and System Software descriptor are used. 

groupInfoLength: This is a 16-bit field indicating the length in bytes of the descriptor loop to follow. 

groupInfoByte: Not defined in the present document. 

privateDataLength: This field defines the length in bytes of the following privateDataByte fields. 

privateDataByte: These fields are not used. 

7.1 .2 Downloadlnfolndication Message (Dll) 

The Dll message provides information about all the modules that are part of the download scenario. The Dll message 
shall follow the syntax as specified in [1], table 7-6. 

In order to allow for multiple updates to be generated independent from each other and transmitted on the same 
carousel, specific assignment rules for some particular fields are given in annex C. 

transactionld: For Downloadlnfolndication messages the id part of the transactionld shall be in the range 
0x0002-0xFFFF to differentiate it from a DownloadServerlnitiate messages. 

The transactionld is equal to the groupid (group number) in the corresponding grouplnfo structure in the DSL 

downloadid: is equal to the transactionld. 

Semantics of the modulelnfo structure: 

moduleld: field is an identifier for the module that is described here further. 

Applying the procedure described in annex C, 

Bits 15.. 8 - has the same value as the LSB of groupid in the corresponding grouplnfo structure in the DSI referencing 
this particular download. 

Bits 7..0 - is the moduleld of a particular download, supporting 256 modules. 

The maximum number of modules in this case is limited to 256, which can be considered as sufficient for system 
software update. 

module Version: field is the version of the described module. 

Applying the procedure described in annex C, this value is also reflected in the LSB of the transaction id in the 
corresponding grouplnfo structure in the DSI referencing this particular download. 
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7.1 .3 DownloadDataBlock Message (DDB) 

The DDB message is used to convey module payloads. The message syntax shall be as specified in [1], 

table 7-7. The DSM-CC section syntax shall follow that defined in [1], table 9-2 and clause 9.2.2.1. 

moduleld: is equal to the moduleld of the module to which this block belongs. 

module Version: is equal to the module Version in the DII modulelnfo structure of the module to which this block 
belongs. 

blockNumber: identifies the position of the block within the module. Block number shall be the first block of a 
module. 

7.2 Standard data carousel descriptors 
7.2.1 SSU module type descriptor 

The SSU_type_descriptor contains the type of the SSU module. 

Table 7: Syntax of SSU_type_descriptor 



Syntax 


No. of bytes 


Remarks 


Type descriptor{){ 






Descriptor tag 


1 


OxOA 


Descriptor length 


1 




SSU module type 


1 




} 







Semantics of the type_descriptor: 

descriptor_tag: This 8-bit field identifies the descriptor. For the SSU type descriptor it is set to OxOA. 
descriptorjength: This 8-bit field specifies the number of bytes of the descriptor immediately following this field. 
SSU_module_type: This is an 8-bit field, types are describes as following: 

0x00 : executable module type; 

0x01 : memory mapped code module type; 

0x02 : data module type; 

0x03 to OxFF reserved for future use. 
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Annex A (normative): 

Repetition rates for DSI and DM messages 

The DSI and each DII shall be repeated at least every 5 seconds. 
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Annex B (informative): 

Locating the appropriate system software update service 

The NIT/BAT, PMT, and the standard update carousel or Update Notification Table define a hierarchy of selection 
mechanisms so as to allow a receiver to locate and identify the appropriate system software update service. 

First a receiver should attempt to locate the appropriate transport stream in a network by examining the NIT and (if 
available) the system software update BAT. The NIT or BAT may contain OUI unspecific linkage descriptors or 
multiple instances of descriptors identifying the receivers OUI. Further exploration of each of the remaining candidate 
services will be required. 

The PMT of each system software update service may contain specific OUIs, in which case the receiver can conclude if 
the service is relevant, i.e. system software update data for it is currently and/or will in the near future be broadcasted. It 
is possible that the relevant signalling in the PMT did not identify any specific OUI(s) relating to a system software 
update service and refers to a standard update carousel. If this is the case then the group compatibility descriptor 
contained in the DSI shall contain OUIs for all organizations for which this system software update service is relevant. 
It may be the case that at this point in time system software update data for some (or even all) OUIs listed is not actually 
available. However, the rule is still valid as it allows a receiver to determine if this system software update service is 
relevant. This allows a receiver to constrain scanning for available system software updates to a single service after 
initial scan. 

NOTE 1 : In any case there may be multiple locations for the receivers system software update if the selector bytes 
do not provide additional identification for the receiver to distinguish between multiple system software 
update services addressing its OUI. Also the location of a system software update service for a receiver 
may move or may be cancelled. The receiver should be robust against this. 

NOTE 2: Only in case a standard update carousel is identified with a single OUI a receiver may be able to identify 
its system software update service component as exclusive (i.e. no sharing with other manufacturers). 
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Annex C (informative): 

Recommendations for transferring system software update 

service data from receiver manufacturer to network operator 

In order to allow for multiple downloads to be transmitted on the same elementary stream, specific assignment needs to 
be applied for particular fields, proposed in the following clauses. Main purpose is to avoid overlap between Groups 
(=downloads) without any need for pre-agreement, i.e. one-layer carousels can be created independently and assembled 
into a two-layer carousel at some later point. Just to be clear, this is additional profiling proposed for DVB System 
Software Update and not interpretation of the existing DVB Data Carousel specification. When the transport format in 
use is MPEG-2, the DSI is encapsulated in a single MPEG-2 section. Thus the number of Groups is limited by the size 
of this and allows approximately 150 Groups to be described depending upon the level of detail for the description of 
each Group. 

Using 8 bits of the moduleld field (MSB) to map to 8-bits in the identification sub-field (LSB) of the transactionid 
would then allow 255 groups, which fits nicely with the =150 maximum described above. This leaves 8-bits of the 
moduleld (LSB) for discriminating between Modules related to each Group - as linked by the other 8-bits of the 
moduleld as described above. 

The module Version could also be used to link changes in the download by mapping to 8-bits in the version sub-field of 
the transactionid (LSB). 

The file delivered from the manufacturer to the broadcaster should preferably be in transport stream format (i.e. a 
sequence of 188 bytes long MPEG-2 TS packets). The manufacturer takes care of generating the file with a full 
continuity counter run through or the broadcaster has to ensure proper remultiplexing in this respect, which means some 
further arrangement is necessary between manufacturer and broadcaster. All other fields in the transport packet can be 
considered as uncritical and can be easily replaced by remultiplexing. Normative repetition rates of the DSI and DIIs are 
defined in annex A. 
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